• Classes are themselves objects. Class variables are really instance variables of class objects, and class methods are instance methods of a class object. Class objects are real, denotable objects in ScriptX that can be queried, assigned to variables, and acted upon in the same ways as all other objects. Class objects exist in a hierarchy, with each class object inheriting information from the classes "above" it in the hierarchy. Subclasses add or refine information that makes them more specific than the classes higher up in the hierarchy. Class and instance variables are inherited through the class hierarchy. Each class is an instance of its metaclass. For a description of the Kaleida metaclass network, see the "Object System Kernel" chapter in the ScriptX Components Guide.

• Classes and objects defined using the ScriptX language become fully-featured, first-class representations in the ScriptX environment. They interact seamlessly with existing objects and with the language. Although there are internal differences, there is no distinction, in programming interface, between a scripted and a non-scripted class. This allows title and tool development to take place in a modular and incremental fashion, with the ability to re-use and specialize any user-developed classes and objects.

• Methods, like class and instance variables, are inherited through the class hierarchy. When a generic function is invoked, if the particular object that it is invoked on does not define a method for it, ScriptX searches for an appropriate method in each superclass up the inheritance tree until an implementation is found. (The system maintains an efficient dispatch cache to make this searching essentially negligible.) That method is then invoked, with the original arguments, and it operates on the original object.

• Methods are invoked indirectly through the use of generic functions, allowing for the separation of interface and implementation. Generic functions allow you to use a single generic name and argument list to refer to multiple implementations of the given generic function that may exist in different classes. In object-oriented programming terminology, this behavior is known as polymorphism. Generic functions are called identically to regular functions, with the restriction that a generic function always has a first positional argument, its target object.

• When classes or instances are multiply inherited, instance variable access and method dispatch become more complicated. (Method dispatch determines which method implementation is selected when a generic function is called, as just described.) In singly-inherited classes, the search for an appropriate implementation of a generic function is linear. If a method definition is not found in the current class, its superclass is searched, and so on up to RootObject. In multiply-inherited classes, the order in which each class is searched determines which method is invoked, especially in cases where different superclasses may define different implementations for that generic function. ScriptX searches the class hierarchy in a depth-first, topological fashion. (For more information on inheritance, see "Multiple Inheritance" on page 122 of Chapter 6, "Defining Classes and Objects.") Each individual superclass is searched before any common superclasses are searched.

• Objects that persist between user sessions can be saved to the ScriptX object store. Program elements, including objects, classes, functions, methods, variables, and modules, can be saved to the object store, just as other objects that represent data are saved. The object store is designed for flexible load management-objects can be preloaded into memory for better performance. In the object store, objects are stored in a variety of containers, which are themselves objects. Once data or program elements are stored in containers, they can be moved from system to system, from platform to platform, to run on any system that supports the Kaleida Media Player.

• Memory management is integrated into the ScriptX environment, and is invisible to the ScriptX programmer. Memory allocation is automatic and occurs when objects are created. Memory deallocation is also automatic; memory for unused objects is reclaimed through the use of a real-time, incremental garbage collector when there are no longer any references to the object. The "Memory Management" chapter of the ScriptX Components Guide describes memory management with the Kaleida Media Player.

• Access to instance and class variables, the getting and setting of values, is implemented through accessor methods. Each class and instance variable is associated with a corresponding getter method that returns its value. If the value of a class or instance variable can be changed by a script, there is also a corresponding setter method that sets its value. It is this implementation of variable access that enables ScriptX to support encapsulation of data in objects.

This document is part of the ScriptX Language Guide, one of the volumes of the ScriptX Technical Reference Series. ScriptX is developed by the ScriptX Engineering Team at Apple Computer, successor to the Kaleida Engineering Team at Kaleida Labs, Inc.

Copyright 1996 Apple Computer, Inc. All Rights Reserved.